When multiple environments share the same custom domain structure
(e.g., zerg.staging.zergrush.dev, zerg.testing.zergrush.dev), the
hostnameForIngress function derives the same service name (svc:zerg)
for all of them because it only reads the first DNS label of the TLS
host.

Add a tailscale.com/service-name annotation that takes precedence
over the TLS host for service name derivation. This lets operators
explicitly control the Tailscale Service name per Ingress:

  annotations:
    tailscale.com/proxy-group: zerg-west1-staging-ingress
    tailscale.com/service-name: zerg-west1-staging

The annotation is optional — without it, existing behavior is
unchanged (service name derived from first DNS label of TLS host).

Relax the Ingress TLS validation to allow multiple hosts within one
TLS entry. The first host is used for service name derivation (or the
tailscale.com/service-name annotation). Additional hosts are served
using the same custom TLS cert from secretName.

This is needed for serving both the primary domain and apex domain
(e.g., zerg.zergrush.dev + zergrush.dev) with the same wildcard cert.

Only one TLS entry is still enforced (multiple entries are rejected).

…TLS entry

Previously, when an Ingress had multiple hosts in a single TLS entry
(e.g. hosts: ["zerg.zergrush.dev", "zergrush.dev"]), only the first
host got the custom cert registered. Additional hosts failed with TLS
internal error because the proxy couldn't find a cached cert for them.

Fix by changing ingressCustomTLS.host (string) to hosts ([]string) and
propagating all hosts through the cert registration pipeline:
- copyCustomTLSSecretData writes cert/key data for every host
- ingressHTTPSHosts includes all custom hosts in serve config
- CustomTLSCerts map is populated for all hosts
- handlersForIngress accepts rules matching any TLS host

…ts.net domains

When a user provides a custom TLS cert via Kubernetes Ingress spec.tls,
the proxy should serve it regardless of x509 chain or domain validation
results. Previously, validCertPEM would reject certs that failed
verification (e.g., wildcard cert not covering the apex domain,
self-signed cert, private CA), causing TLS internal errors for
additional hosts in multi-host TLS entries.

Add ReadRaw to certStore that reads cert/key checking only parseability
(tls.X509KeyPair), not x509 chain/domain validity. In
GetCertPEMWithValidity, when a domain is definitively not ACME-managed
(errNotACMEManaged) and doesn't end in .ts.net, fall back to ReadRaw
when getCertPEMCached returns errCertExpired.

…CME certs

For custom (non-ts.net) domains, check the pod's state Secret before
the domain-specific Secret when looking up TLS certs. Custom TLS certs
from Ingress spec.tls entries are written to the state Secret by the
operator, while ACME-provisioned certs are stored in domain-specific
Secrets. Without this ordering, an ACME cert for the same domain would
shadow the user-provided custom cert.

For ts.net domains, the lookup order is unchanged (domain-specific
Secret first) to avoid extra API calls on the common ACME path.